为什么要做Code Review
软件质量的视角
一切为了质量！
我们的理想：用更短的时间，更少的成本，以更高的质量，完成更多的范围。
然而，理想很丰满，现实很骨感。从我做起，从Code Review做起。
人个能力的视角
“你有一个苹果，我有一个苹果，彼此交换一下，我们仍然是各有一个苹果；但你有一种思想，我有一种思想，彼此交换，我们就都有了两种思想，甚至更多。”——萧伯纳
萧伯纳说的对。
如果拿一个苹果，换一个思想，你换不换？
不管你换不换，反正我是换了。不过，如果苹果能改成一顿饭，就更好了，因为我不太喜欢苹果。
做有意义的确Code Review
原则问题
是代码有问题，不是你有问题
Code Review一定是对事不对人，代码的主人一定不要有负担。如果有必要，可以考虑 “匿名评审” 。
Code Review重点在于交流讨论，不要局限于既有代码，大可以谈谈理想。
有问题却不解决，那就是你有问题
评审是为了发现问题，提出问题的解决方案或思路，为了更好地解决问题。如果发现了问题，却不着手解决，好比“道不行，乘桴浮于海。”
自己的问题自己负责、自己解决
境界问题
“错别字检查”
一切编码规范的硬性要求，本质上都是“错别字检查”，没有例外。
一切“错别字检查”，理论上都可以用工具来评审，但是有例外。
这个境界的代码评审是最低级的，却是我们最常做的，这是一个错误！
就像客观题目考试，已经给了学生标准答案，你做为老师还在哼哧哼哧地帮学生判卷一样。
所以，我们应该强调编码规范，对新员工加强编码规范的检查，而不是在Code Review会议上花费大部分精力讨论。
新员工的编码规范检查，使用 代码走查 足矣！
前提：你得有一个好的编码规范
这里，是良好习惯的起点
“跑题检查”
你的设计是否真的能够解决你的问题？你的作文是否真的表达了指定的主题？
请先陈述设计，不仅仅展示代码
做为新手或新接手，你对当前问题了解的是否全面？
让大神或业务精熟者帮你找坑。
这里，是掌握业务的体现
“谋篇布局欣赏”
下面我要谈谈的我的：设计模式？架构？设计原则？低耦合？高内聚？可扩展性？可维护性？性能？并发？
菜鸟：好吧，我承认我没怎么听懂，不觉明厉
老司机：高，实在是高，如果是我的话，估计做不到这样好
大神：嗯，我觉得还可以这样搞，也许会更好一些。
从“跑题检查”到“谋篇布局欣赏”有个质的飞越，这正是能力的体现，高手决胜于此。
这里，你就是大神
杂七杂八
欲善其事，先得其器
能让工具做的事，就不要让人来弄，因为你永远也达不到工具的速度、准确性和耐心
看看你的工具箱有哪些东西，立志做一个哆啦A梦
在这里，我真不想列举工具清单，因为我也没用过。
17款最佳的代码审查工具：http://www.codeceo.com/article/17-best-code-review-tools.html
让代码优化日常化
一切想通过一次性会议就解决问题的想法，都是幼稚的。代码能力的提升，只有通过日常的坚持才能实现。
走查，走查，边走边查。所以代码走查才是王道。
不要和我嚼文字，我说的走查，就是指一切非正式的代码质量管控办法。比如：
强制使用checkstyle、findbugs等静态代码检查工具
制度上限制新员工所有代码必须通过指导人同意后，才能提交
将代码质量与个人绩效关联
好吧，我不说了，我知道，你不想这样，其实我也不想。